Revisionist History
Volume Number: 12
Issue Number: 6
Column Tag: Version Control
Organic tools for an unpleasant task
By Paul Snively
Rationale
Revision control is often neglected. Of all the companies I’ve been with, only three
have even attempted to use it - and at two of these, the decision was driven by
engineers on particular projects, sometimes with the result that projects couldn’t
share files because their revision control systems weren’t compatible. Don’t get the
idea that I’m a great lover of revision control, either. I’ve always found RCS,
Projector, and previous versions of SourceSafe to be so confusing and unwieldy as to be
more trouble than they were worth for groups of anything less than about five users.
If I hadn’t found a couple of systems worth writing about, this article wouldn’t exist.
Nevertheless, two observations about software development today will
demonstrate the pertinence of the subject. First, many of us are doing cross-platform
development and struggling to maintain feature-for-feature compatibility between
platforms. Second, a lot of what we professional programmers do these days isn’t so
much original development as synthesis - taking a collection of code, some of which we
wrote and some of which we didn’t, and gluing it all together, making whatever changes
to the pieces prove necessary along the way. A revision control system becomes
indispensable in cases where you have to track common code vs. platform-specific code
and in cases where you’re using some existing code and making changes to it (possibly
at the same time that the original author makes changes to it!). And of course, you
could be trying to do both at the same time.
Note that neither of these common scenarios has anything to do with having
multiple programmers on a project. These are situations that I, and probably you,
have encountered even when we’re working on things all by our lonesome. Don’t be
seduced into believing that revision control is only for projects involving large
groups.
Many of you may have prior experience with one of the older revision control
systems - Projector/SourceServer for those of you who cut your teeth on the MPW or
Symantec environments, SCCS or RCS for us greybeards in the industry. I’d like to
take a look at a couple of relative newcomers to most of us, even though they’ve both
been around for a while: Metrowerks’ CodeManager, née SourceSafe, and UNI Software
Plus’ VOODOO.
Is It Safe?
CodeManager 1.0.3 (DR1, with patches available at http://www.metrowerks.com/
tools/software/updates/cm1) is the Macintosh version of SourceSafe, which was
purchased some time ago by Microsoft. As a result, one of CodeManager’s major selling
points is its cross-platform availability. Unfortunately, one aspect of CodeManager
that eases the burden of keeping it cross-platform is that it is a command-line system
- that is, it runs as a set of tools under MPW or ToolServer. This is probably not so
bad if you’re an old hand at SCCS/RCS/Projector, especially if you’re still an MPW
user anyway. As a CodeWarrior user since DR/1, though, I can afford neither the disk
nor the RAM space to maintain both CodeWarrior CW8 and MPW at the same time, so I
had to get ToolServer up and running under CodeWarrior. That alone was a sufficiently
daunting task that it nearly made me give up on CodeManager, which would have been a
shame, because there are things to like about CodeManager. Hint to you: if you’re going
to install CodeManager under ToolServer, don’t forget to rename
UserStartup•CodeManager to UserStartupTS•CodeManager. Hint to Metrowerks:
most of your CodeManager users are also likely to be CodeWarrior users, so how about
providing an installer that will install ToolServer and CodeManager into an existing
CodeWarrior installation and then delete the desktop file(s) before restarting, thereby
forcing the Finder to rebuild the desktop?
Once I got CodeManager up and running under ToolServer, I was pleasantly
surprised to find that it doesn’t remind me as much of SCCS/RCS/Projector as I had
expected it to.
Projects vs. Files
Historically, revision control systems that I’ve used have been file-centric:
useful for tracking changes to any given file in a project, but poor at tracking changes
to the project (integrating one file’s contents into another, renaming a file in the
project, renaming a folder, moving a file from one folder to another, etc.). If you’ve
spent any time wrangling any but the smallest project, you probably know that getting
the structure of the project right is at least as difficult as getting the content of the
project right.
CodeManager, to its considerable credit, is project-based. Not only does it
support traditional file-level revision control, but groups of files belong to projects
and can be referred to collectively. Projects can be nested, and in this sense projects
resemble folders. Unlike folders, however, projects can be deleted and later
recovered.
Projects can also share files - an update to a file in one project is automagically
reflected in the file in any other projects that include it. This feature is especially
handy when you have multiple projects that rely on a common code base. As long as the
common code is shared among all the projects that use it, all the projects are kept up
to date without any extra effort.
It may be the case, though, that your project is using code from someone else’s
project and your schedule is somewhat ahead of theirs. You may need to freeze your
project before they do. That’s ok - you can “pin” whatever file(s) they’re sharing
with you at any version at any time. This doesn’t break the shared link; it just gives
you a specific “snapshot” of the revisions of that file. You can unpin the file at any
time to catch up to the other revisions.
In a similar vein, you can “branch” a shared file if you need to revise it in
directions that you know differ from those of the other sharers of the file. Unlike
pinning, branching does break the shared link. However, a history of the link is still
maintained, so you can examine the common heritage of the branches if you need to.
As you might expect, CodeManager also allows you to merge branches of a file, in
the event that the combined revisions would be appropriate for all projects sharing the
branches. It’s perhaps worth pointing out that CodeManager can handle both text files
and binary files, although its means for determining which is which is questionable: it
reads the file and, if and only if it discovers any zero bytes, considers it a binary file.
This behavior can be overriden with an environment variable that specifies, say, that
all files whose names end with .sit, .µ, or .rsrc are binary files, and all others
should be considered text. There are also command-line options to the relevant
commands to specify that when comparing files both forks are to be compared.
CodeManager’s ability to do diffs and merges on binary files is one of the things that set
it apart from earlier revision control systems.
My favorite project-based feature, though, is labels. You can attach a label to an
entire project at any point in the revision of that project, and then, at any point down
the road, you can retrieve the entire project by label. The most obvious application of
labels to me is at major milestones: when your project goes alpha, give it a label
saying so; when it goes alpha two, label it; when it goes beta, label it. This way you
have an air-tight history of your project’s milestones, which can be extremely
helpful in analyzing the project’s schedule, budget, size, feature set, bug history, etc.
In particular, imagine how much your QA staff doing regression testing will love being
able to retrieve any version of the project any time they need to.
Finally, a feature that is, as far as I know, completely unique to CodeManager:
you can configure it in such a way that multiple people can check out a file at the same
time, and when the various users of the file check their revisions back in,
CodeManager will attempt to merge them. If none of the users have modified the same
line, then the merge is considered to be without conflicts and happens silently. If, on
the other hand, two or more users have modified the same line, then whoever checks
their revisions in later will have the opportunity to resolve the conflict, hopefully in
consultation with whoever checked in the earlier revision. Many’s the time I’ve
wished for a revision control system that recognized that it’s quite rare for my
coworkers and myself to be working on the same lines in a source file, but it’s
relatively common for us to need to work on the same file. CodeManager makes this as
painless as I think it can realistically be made.
Administration of CodeManager is a straightforward matter of editing some text
files and possibly using some extra tools once you have logged in under the Admin
account. I encountered no particular surprises here, good or bad.
Déjà Voodoo
VOODOO 1.7, from UNI Software Plus in Austria, takes a similar tack to CodeManager
in that it is project- rather than file-based, and also stores deltas of either text or
binary files for space-efficiency. VOODOO, however, takes the project-based concept a
step further by supporting the notions of a component, a variant, and a revision, all of
which are orthogonal to each other - VOODOO stands for “Versions Of Outdated
Documents Organized Orthogonally,” which beats “BASIC” for the Most Tortuous
Acronym award. “Orthogonal” just means that each of these concepts is treated
independently of the others: in other words, VOODOO cleanly differentiates among the
components of a project, the variants of those components, and the revisions of those
variants.
For example, let’s say that, being serious about what you do, you do all of your
development on your PowerMac with no optimizations on - especially instruction
scheduling, because that totally wrecks the mapping from your source code to your
object code, and Metrowerks’ debugger gets confused (no slam to Metrowerks;
practically any source-level debugger gets confused in the presence of instruction
scheduling). Of course you generate a .SYM file, and maybe you even include traceback
tables because MacsBug now groks them. Of course, your code is big and slow, but
that’s because it’s your development version. On the other hand, by the time you’re
ready to ship, it’s out with the traceback tables, out with the .SYM file, and hopefully
in with the instruction scheduling, global optimizations, etc.
That’s one component - the project file - with two variants, debugging and
optimized, and some number of revisions of those variants, such as when you try the
level-four global optimizations and they cause your project to crash, so you scale down
to level-two global optimizations and everything works fine.
This may sound like a lot to keep track of, and it is, which leads me to another
favorite feature of VOODOO, namely its graphical interface. As an example, consider
McKinley. This is my shot at creating a Netscape 2.0 plug-in that supports VRML 2.0
and the “Moving Worlds” proposal from Netscape, Silicon Graphics, and Apple, with
object behaviors being programmable in Scheme. In the McKinley project, there are
four distinct major subsystems, namely Apple’s freely available 3DMF parser, the
freely available Mesa 3D graphics library, the freely-available MzScheme Scheme
interpreter, and the freely available Netscape plug-in shell. With all of these sources
yanked off the net, it’s a great project for revision control. VOODOO’s graphical
representation looks like Figure 1.
The plain rectangular boxes are structure nodes. Like folders on your disk,
they’re there to help you keep organized.
The rectangles with the document icons are components. A component typically
maps onto a file, and in fact VOODOO simplifies that mapping by allowing you to add
files to your project as components. VOODOO will also allow you to drag and drop files
into your structure nodes as you’re defining the structure of your project. Symantec
users, rejoice! You can drag files directly from your project files into VOODOO.
CodeWarrior users, grumble! You can drag and drop files into your projects, but not
out. Interestingly enough, VOODOO is also a drag-in-only proposition. (An analogy
with Roach Motel suggests itself.)
Figure 1. How a VOODOO project looks
The circles are used to indicate the variants of a component. In the McKinley
project, you can see that of the visible parts only the project files themselves have
more than one variant, debugging and optimized, as described above. Source files
might too, however - for example, if you wished to maintain a variant of your source
with debugging-assistance code included vs. one without. In the shot above, each
variant actually refers to the same file. When you actually branch off a new variant of
a file, it looks like this:
Figure 2. Two variants referring to one object
vs. an object for each variant
The free-standing document icons are called version groups. In the 68K case,
there’s only one, because the 68K optimizer doesn’t break the debugger so badly. In
the PPC case, there are two, to indicate that the debugging and optimized variants refer
to two different objects. This takes a little getting used to, but it’s very convenient to
be able to easily specify whether you want a development variant or a production
variant of your project. Variants might also be used for those components of your
project that just can’t be completely identical across platforms (you might have a
Macintosh variant and a Win32 variant, for example).
Finally, you’ll notice that some of the structure nodes have arrows extending
from them. This indicates that they have child nodes, but that those nodes are
currently collapsed so as to allow you to focus on the portion of the project at hand.
Once you’ve defined the structure of your project, actually using VOODOO to store
and fetch components is simple. After making changes to files, you can just drag them
to the VOODOO project window to store them and VOODOO will automatically figure out
where in the tree they go. Failing that, you can use a dialog to select which components
to store, specify locking of local copies, and the like.
Fetching components is practically as easy: you can select any structure node, a
component node if it doesn’t have more than one version group, or any version group
icon, and fetch the most recent version(s) of those components, specifying in the
process whether you want the relevant version group(s) locked, etc.
Being project-based, VOODOO also tracks the history of the project as a whole:
you can view structure changes, data changes, or both. As with CodeManager, you can
name particular points in time (called “Defining a Configuration” in VOODOO), and
when viewing the history of the project, you can roll back instantly to any such named
point in time.
Conclusions
Revision control has come a long way since my SCCS/RCS/Projector days. It’s good to
see two systems that take a holistic stance toward projects, recognizing that a project
that I call “1.0b1” consists of some components that have been revised 100 times and
others that haven’t been at all. And it’s nice that they both deal with binary files as
well as text.
CodeManager does some things that I’d love to see in VOODOO. The feature of
allowing multiple checkouts of text files and making an effort to merge them together
upon check-in is a big win for me. Generally speaking, VOODOO’s uniform treatment
of everything as a binary is elegant, but some kind of comparison/merging facility
would be a big help. And if you work in a mixed shop, SourceSafe/CodeManager is very
hard to beat.
On the other hand, VOODOO does some things that I’d love to see in CodeManager.
Being a standalone application with a graphical interface and drag and drop support is
one. Also, there’s its uniform treatment of variants as well as revisions (although
careful use of branching in CodeManager could probably accomplish the same result).
Personally, I use VOODOO on an everyday basis. It’s the tool that got me religious
about revision control in the first place. It makes revision control make sense to me,
and makes it a fun process rather than a chore. Some time ago, in responding in
netnews to a query about revision control, I said about VOODOO:
“I use VOODOO 1.6 practically every day, and I continue to be amazed that it took
this long for revision control to become even reasonable, let alone pleasant. VOODOO
recognizes that not all the world is a text file. It recognizes that variants are distinct
from revisions. It recognizes that I’m using a windowing system with a mouse. At this
point, no matter where I go, no matter what other development tools I’m using, I’ll be
using VOODOO to keep me from shooting myself in the foot when it comes to version
control.”